Third Generation Partnership Project (3GPP) defines a mobile core network called the Evolved Packet Core (EPC) that allows mobile nodes (3GPP User Equipment (UE)) to attach to heterogeneous access networks including 3GPP accesses and non-3GPP accesses. The all IP-based network architecture makes convergence of the fixed and mobile networks possible.
There is no guarantee that the access network securely transfers user traffic to the EPC, when the mobile node attaches to an untrusted non-3GPP access network. Therefore, the mobile node establishes a pair of Security Associations (SAs) with a security gateway, called the evolved Packet Data Gateway (ePDG), inside the EPC. All user traffic is then tunneled through a secure bi-directional tunnel by applying the established Security Associations to the traffic. IP mobility management (IPMM) is done either in a network-based manner or in a client-based manner. In the former case, Proxy Mobile IPv6 (PMIPv6) is used and the ePDG serves as a Mobile Access Gateway (MAG). In the latter case, Dual Stack Mobile IPv6 (DSMIPv6) is used and the ePDG does not get involved in the IP mobility management at all.
The secure tunnel is commonly established by using Internet Protocol Security (IPsec), a protocol for securing IP communications by authenticating and encrypting IP packets. IPsec can be implemented in a host-to-host transport mode, as well as in a network tunnel mode. In transport mode, only the payload (data) of an IP packet is encrypted and/or authenticated. In tunnel mode, the entire IP packet (data and IP header) is encrypted and/or authenticated, and then encapsulated into a new IP packet with a new IP header.
A security association (SA) may be defined as a simplex connection between two entities that affords security services to the traffic carried by it. Security services are afforded to an SA by the use for example of either of the protocols Authenticating Header (AH) or Encapsulating Security Protocol (ESP). For a tunnel mode security association (SA) (a security tunnel) there is an “outer” IP header that specifies the IPsec processing source and destination, plus an “inner” IP header that specifies the (apparently) ultimate source and destination for the packet. The security protocol header appears after the outer IP header, and before the inner IP header. Depending on which protocol is being employed the outer IP header are afforded protection (in case AH is used) or not (in case ESP is used). The outer IP header source address and destination address (the outer IP address of the IPsec SA) identify the endpoints of the tunnel (the encapsulator and decapsulator). The inner IP header source address and destination addresses ((the outer IP address of the IPsec SA) identify the original sender and recipient of the data (from the perspective of this tunnel), respectively.
Extensible Authentication Protocol (EAP) is a mechanism for authentication and session key distribution using the Authentication and Key Agreement (AKA) mechanism. EAP-AKA protocol is developed by 3GPP. Authentication and authorization based on EAP-AKA is done during the attachment procedure of the mobile node to EPC through an untrusted non-3GPP access network. The mobile node and the ePDG run Internet Key Exchange version 2 (IKEv2) to establish an IPsec security association (SA). IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs). The mutual authentication is performed between the mobile node and the AAA server (an unit that provide IP functionality to support the functions of authentication, authorization and accounting) in the EPC, and the ePDG serves as a pass-through authenticator. In this way, IKEv2 is used as carrier of EAP messages. The ePDG assigns an inner IP address to the mobile node during the attachment procedure by using the configuration payload. When the IPMM is done in a network-based manner, an EPC IP address is assigned as an inner IP address for the mobile node. When the IPMM is done in a client-based manner, the ePDG assigns an IP address from its own IP address pool to the mobile node. Then the mobile node uses the inner IP address as a care-of address (CoA) in the DSMIPv6 context.
In 3GPP a mobile node needs to take a full authentication and authorization procedure when it attaches to an untrusted non-3GPP access network. The procedure requires a lengthy message exchange among the mobile node, a security gateway and an AAA server. The authentication and authorization procedure takes at least three round trip time (RTT) between the mobile node and the AAA server in the mobile core network. From a security perspective, there is no need for the mobile node and the mobile core network to perform full authentication and authorization procedure whenever it changes access, as far as there is evidence that the two have mutually authenticated to each other. It would therefore be desirable if the mobile node and the mobile core network could omit the full authentication and authorization procedure even when the mobile node performs an inter radio access technology (IRAT) handover.
The Internet draft “MPA using IKEv2 and MOBIKE draft-yacine-preauth-ipsec-01”, discloses how a call can be transferred between first and second untrusted access networks and respective first and second secure gateways connected to a core network. When the user terminal, UE, residing in a first access network discovers a second gateway, belonging to a second access network to which it may attach, it starts an authentication procedure with this second gateway using IKEv2 while the UE is still attached to the first access network using an already established IPsec tunnel. The IKEv2 authentication procedure establishes an IPsec tunnel between UE and the second gateway. When handover to the second access network subsequently takes place, the source outer address of the IPsec tunnel is updated using the MOBIKE protocol and the new IPsec tunnel can be used without performing a complete reauthentication procedure.
A drawback with the prior art is that traffic may unnecessarily be sent via the newly established IPsec tunnel as soon as the IPsec tunnel is established, because the UE and/or security gateway cannot determine to which IPsec tunnel (the old or the new) the traffic is to be injected. A workaround for this problem would be to establish the IPsec tunnel as close as possible before the UE performs the handover. However, it may be difficult or even impossible to predict the time when the handover is to take place which may thus result in a too early establishment of the IPsec tunnel or a too late establishment of the same which would trigger the start of the full authentication and authorization procedure resulting in an inefficient handover.
There is thus a need for a secure and efficient solution that eases handover to an untrusted access network.